When a browser requests a webpage from a web server there is usually some inherent latency due to the need for the web browser to request each resource identified in the web page. This latency is caused by the web browser being required to individually request each resource as the web browser comes across the request for the resource during the rendering stage.
The basic steps involved in displaying a web page on a browser include the web browser requesting a page from the web server.
The web server then determines which web application is to handle the request, e.g. asp, php, jsp etc. A request is made by the web server to the determined web application to render the page. The web application renders the page content and streams it back to the web server.
The rendering of a page involves the execution of code to transform a template specification for the page into browser readable content (typically HTML, but not restricted to this only).
At this point the assembled page may include links to a number of additional resources that supplement the text content, such as images and script code (<script src=“url” . . . > and <img src=“url” . . . >), as well as other resources such as CSS references (<link type=“text/css” href=“url” . . . >).
For a standard web page, the page content is sent back to the browser with all the resources referenced individually in the HTML.
Upon receipt of the web page, the browser parses the content looking for other resource links and requests each resource in turn from the web server as the browser renders the page. Each of these requests causes the web server to pass the request onto the web application or stream a file from the file system. This causes a latency problem since each resource has the request/response time of the connection in addition to the raw data transfer time.
FIG. 1 shows a flow diagram of the first stage of a browser requesting a web page from a web server.
The process includes a web browser requesting a web page from the web server. The web server then either streams the page back if static, or if dynamic then requests the page from a web application. The web application renders the requested web page by accessing the page data and including any links to resources within the web page. The page content is then rendered. The web application then streams the rendered web page back to the web server, which in turn renders the web page back to the web browser via the Internet.
FIG. 2 shows a flow diagram of the second stage wherein a browser renders the HTML page received from the web server.
As the web browser renders the web page, in order to display the web page, the page content is parsed by the browser. When the browser finds a link in the web page that references a resource, that resource is requested. For example, if the web browser parses a first reference to a style sheet, it makes a request to the web server for that style sheet. The web server then fetches the style sheet. Each time that the web browser sees another link to a resource reference, a further request is made to the server and a further fetch cycle is carried out to retrieve the resource. The same steps occur when the browser finds links to each script that is required, and links to each image referenced in the web page.
The requirement for the web server to make separate requests for each resource identified or referenced in the web page causes a delay or latency in the system.
Once all the resources have been retrieved from their various sources, the complete web page is displayed.
In an attempt to reduce the latency, it is known for software developers to explicitly and manually concatenate resource content according to its type where it is static, for example, when the resource content is JavaScript or cascading style sheets (CSS). This type of combining is only carried out at the development stage when the web page is being built, and so does not allow web pages that have not been explicitly built in this manner to be adapted to reduce latency at a later time.
It is also known that some components, such as compiled Ajax and JavaScript libraries etc, are able to dynamically emit script, and allow all scripts that it generates to be combined into a single resource. Each type of component however is only able to control the resources that the component is aware of and so the grouping in this manner only allows a single request to be made for all scripts of that particular component. As a result, it is still a requirement and common practice to use multiple components. These multiple components also result in multiple resource requests from the browser when the HTML web page is rendered.
It is also known to combine, compress and cache resources as the function of a component, but again this requires effort on behalf of the developer to specifically manually identify those resources to be combined and compressed at the time when they write the software. Also, this approach is limited for use when combining static resources, so it is not possible to have this apply to the dynamic resource references emitted by the components previously mentioned.
In WO 01/19052 a system is described wherein the scripting language content in a web page to be transmitted is reduced by compressing the content.
In U.S. Pat. No. 7,054,917 a method is described that attempts to reduce latency by combining uniform resource locator (URL) requests associated with advertisement servers into one request.
In US Patent Application Publication 2004/215665 a system is described that reduces the amount of data being transmitted by combining, compressing and transcoding HTML data before transmitting the data to a client device.
None of the above prior art documents teach a system that enables the reduction of latency of existing web pages. Further, there is no known method of automatically and dynamically arranging image resource requests in a rendered HTML web page such that those image resources can be requested in a single request from the web page as it is being rendered.